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PROCEDE DE COMMUNICATION EMTRE DEUX UNITES. 
ET TERMINAL METTANT EN CEUVRE LE PROCEDE 

La presente invention concerne les terminaux informatiques permettant 
des activites de type navigation sur reseau et offrant aux utilisateurs la 
5 possibilite d'installer des applications. 

De tels terminaux peuvent notamment etre des telephones utilisant le 
protocole d'application sans fil (WAP, "wireless application protocol"), des 
ordinateurs de bureau, des ordinateurs portables ou des assistants numeriques 
personnels (PDA, "personal digital assistant"), lis ont en commun la 
10 caracteristique d'etre relies a un reseau de donnees numerique, qui dans 
beaucoup de cas pratiques est un reseau fonctionnant selon le protocole IP 
("Internet protocol"), notamment I'lnternet. 

Dans le cas d'un terminal "ferme" (exemple: un Minitel), les 
applications prdsentes sur le terminal sont connues et ne peuvent pas etre 
15 changees au cours de la vie du terminal. *jf m 

L'ouverture d'un terminal fait reference a la possibilite offerte v ,a 
I'utilisateur d'installer, et souvent de telecharger, de nouvelles applications 
destinees a §tre executees par le terminal lui-meme. Des exemples de 
terminaux "ouverts", integrant cette possibilite, sont: 
20 • les telephones a telechargement d'applications, par exemple de type 

Java MIDP ("Mobile Information Device Profile", Sun Microsystems, Inc.); 

• les navigateurs possedant des fonctionnalites dites de scripting, par 
exemple de type WMLScript (voir "WAP WMLScript Language 
Specification", version 1.1, WAP Forum, novembre 2001) ou ECMAScript 

25 (aussi appele JavaScript, voir "ECMAScript Language Specification", 

Standard ECMA-262, 3 e edition, decembre 1999), ou accueillant des 
applets; 

• la plupart des PDA, fonctionnant sous les systemes d'exploitation 
PalmOS, WindowsCE, Symbian etc.; 

30 • les ordinateurs de bureau ou portables. 




Les terminaux "semi-ouverts" sont les terminaux ouverts dont certaines 
fonctionnalites ne sont pas directement accessibles aux applications installees 
par I'utilisateur ou telechargees. Par exemple, dans un terminal dont la seule 
"ouverture" est ECMAScript, les applications telechargees ne peuvent pas 

5 acceder a toutes les fonctionnalites du reseau (par exemple, emettre des 
paquets IP n'obeissant pas aux formats des protocotes de transport les plus 
courants, a savoir TCP ("transmission control protocol") ou UDP ("user 
datagram protocol")). Ces fonctionnalites peuvent etre accessibles de facon 
indirecte et controlee. Par exemple, une fonction ECMAScript peut commander 

10 le chargement d'une page via HTTP ("hypertext transfer protocol"), ce qui 
utilise le reseau mais d'une facon controlee. 

Dans des terminaux "semi-ouverts", il y a coexistence: 
• duplications considerees comme "de confiance", par exemple parce 
qu'elles ont ete installees en usine par le fabricant du terminal, ou bien du 
15 fait de la garantie procuree par des moyens teJs que la signature 

electronique de I'application etc.; 
o et d'autres applications qui peuvent etre installees sur le terminal par 
I'utilisateur lui-meme, a son libre choix, mais n'accedent pas aux memes 
droits que les applications de confiance. 

20 Les terminaux "completement ouverts", par opposition, sont les 

terminaux ouverts dans lesquels toutes les fonctionnalites sont accessibles aux 
applications telechargees. La notion d'ouverture d'un terminal depend dans 
une large mesure du contexte dans lequel on se place. Par exemple, 
differentes couches du modele OSI (lien / reseau / session / transport / ...) 

25 peuvent avoir differents degres d'ouverture. 

On s'interesse ici aux fonctionnalites observables a distance, depuis un 
serveur, c'est-a-dire aux fonctionnalites de reseau. Dans ce cadre, le caractere 
"semi-ouvert" d'un terminal implique generalement que des droits d'execution 
observables a distance, accessibles aux applications de confiance, ne sont pas 
30 accessibles aux applications sans confiance (par exemple, le droit d'emettre 
des requetes autres que HTTP sur un reseau IP). Ceci permet a un serveur de 




distinguer, parmi les requetes qui lui arrivent, celles qui proviennent 
d'applications de confiance et celles qui proviennent d'autres applications. II 
petit en particulier distinguer les requetes provenant d'applications 
telechargees des requetes provenant d'applications presentes des I'origine 
5 dans le terminal. 

Dans les terminaux ouverts, il faut tenir compte de la possibilite qu'un 
programme se comporte de fagon trompeuse vis-a-vis de I'utilisateur (cheval 
de Troie). Ainsi, rien ne peut garantir a un serveur qu'une requete provient bien 
de I'utilisateur, et non d'un programme ayant simule I'accord de I'utilisateur au 
10 niveau du reseau. Ce risque ruine la confiance que le serveur peut avoir dans 
les donnees qu'il recoit d'un client. L'hypothese selon laquelle les requetes 
adressees au serveur refletent les actions de I'utilisateur n'est pas raisonnable 
si un cheval de Troie a la possibilite de les envoyer a la place de I'utilisateur.. ' % 

On fera done dans la suite une distinction entre les applications 
15 presentes sur le terminal: 

• applications de confiance: le serveur est pret a falre l'hypothese que ces 
applications ne sont pas des chevaux de Troie. Par exemple, Me 
navigateur WAP d'un telephone WAP peut constituer une application de 
confiance. Un autre exemple peut etre une application Java MIDP 

20 telechargee avec signature; 

* applications sans confiance: le serveur considere que ces applications 
peuvent etre des chevaux de Troie. Par exemple, des applications Java 
MIDP telechargees sans signature sur un terminal peuvent etre des 
applications sans confiance. 

25 La reponse classique au risque de cheval de Troie est de limiter les 

capacites des applications sans confiance. 

La limitation de remission des frames depuis les terminaux semi- 
ouverts se fait generalement de fagon extremement stricte. Seules les 
applications systeme (fournies avec le systeme d'exploitation du terminal) sont 
30 autoris§es a emettre certaines frames. 
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I! devient done impossible a une application telechargee (avec ou sans 
confiance) d'emettre des trames vers un serveur, meme si cette application 
dispose par ailleurs de moyens d'obtenir la confiance du serveur du fait du 
contenu des trames qu'elle emet (exemple: emission de donnees signees) ou 
5 du fait de ses caracteristiques (exemple: signature associee a son contenu). 

Un but de la presente invention est d'offrir une difference de.capacite 
d'envoi de requetes d'un nouveau type entre applications "de confiance" et 
applications "sans confiance", qui soit flexible pour les applications et puisse 
neanmoins etre identifiee par le serveur destinataire. La notion de confiance 
10 peut s'appuyer sur des criteres varies (signature, type d'echange, URL depuis 
laquelle Fapplication a 6te telechargee, etc.). 

^invention propose ainsi un procede de communication entre une 
premiere unite et une seconde unite par Tintermediaire d'un reseau de 
telecommunication, dans Iequel la premiere unite comporte des applications 

15 appartenant respectivement a une premiere famille et a une seconde famille 
presentant a priori un degre de confiance plus faible que la premiere famille. 
Selon un aspect de I'invention, on contraint chaque requete issue d'une 
application de la seconde famille, emise sur le reseau a destination de la 
seconde unite, a inclure un marquage associe a la seconde famille 

20 duplications. Selon un autre aspect de I'invention, on contraint chaque 
requete issue d'une application de la seconde famille, emise sur le reseau a 
destination de la seconde unite, a ne pas inclure un marquage associe a la 
premiere famille, ledit marquage etant inclus dans certaines au moins des 
requetes emises sur le reseau et issues duplications de la premiere famille. 

25 ^invention propose aussi un terminal de communication, comprenant des 
moyens de mise en oeuvre d'un tel procede en tant que premiere unite. 

Le procede permet a certaines applications particulieres ("de 
confiance") s'executant dans la premiere unite d'emettre des trames a 
Tattention d'une seconde unite, generalement un serveur distant, avec la 
30 garantie pour cette seconde unite de Porigine fiable de ces trames. L'inclusion 
obligatoire du marquage pour les applications a priori sans confiance de la 
seconde famille (ou symetriquement son interdiction) distingue, a remission, 




!es trames emises par ces applications a priori sans confiance par rapport a 
ceiles emises par des applications de confiance. Ceci permet au serveur de 
faire le tri entre les requetes acceptables, en lesquelles il a confiance, et ceiles 
qu'il doit rejeter. 

5 II convient que le marquage applique soit completement "etanche", 

c'est-a-dire quMI ne soit pas possible pour une application a priori sans 
confiance de court-circuiter les controles effectues a un certain niveau (par 
exemple: fonctions de requetes HTTP), en attaquant les couches plus basses 
(par exemple: requete d'une connexion TCP). 

10 Dans une realisation du procede, on contraint le marquage, inclus dans 

une requete emise sur le r6seau et issue d'une application de la seconde 
famille, a inclure une indication de la nature et/ou de i'origine de la^ite 
application de la seconde famille. Cette indication consiste par exemple en jd.es 
donnees relatives a la certification de la signature d'une application signee,^ou 

15 encore a I'adresse de telechargement d'une application tel6chargee par 
I'intermediaire du reseau. Elle peut etre utilisee par I'unite distante pour evaluer 
si elle peut faire confiance 3 ('application qui ne pouvait a priori qu'etre jugee 
sans confiance par la premiere unite. ^ 

Grace au procede, des terminaux supportant le telechargement des 
20 applications peuvent echanger des donnees en toute confiance avec un 
serveur, malgre les risques inherents a ces capacites de telechargement 
("ouverture" du terminal). Le procede procure ainsi une protection simple et 
efficace centre les chevaux de Troie. 

D'autres particularity et ayantages de la presente invention 
25 apparattront dans la description ci-apres d'exemples de realisation non 
limitatifs, en reference au dessin annexe, dans lequel la figure unique est un 
schema d'un systeme mettant en ceuvre Tinvention. 

On cherche a permettre a une unite distante telle qu'un serveur 1 
d'obtenir de fagon sOre et souple la confiance dans des requetes revues sur un 
30 reseau de telecommunication R en provenance d'un terminal semi-ouvert 2. Ce 
terminal heberge d'une part des applications de confiance 3, comme par 
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exemple un navigateur web, et d'autre part des applications a priori sans 
confiance 4, notamment des applications que I'utilisateur du terminal a 
telechargees par I'intermediaire du reseau R. 

Les applications a priori sans confiance 4 sont contraintes quant aux 
5 trames ou requetes qu'elles peuvent emettre sur le reseau R, ce qui, dans le 
schema, est symbolise par une couche de controle 5 faisant partie des 
ressources 6 d'acces au reseau dont est equipe le terminal 2. 

La couche de controle 5 verifie que certaines proprietes sont remplies 
par les trames emises par les applications a priori sans confiance 4, Si ces 
10 proprietes sont remplies, la couche de controle laisse passer les trames. Sinon, 
elle peut soit ne pas les laisser passer vers le reseau R et en prevenir 
I'application 4 qui les a emises, soit modifier les trames pour les conformer aux 
contraintes des applications a priori sans confiance. Dans ce dernier cas, la 
trame perd sa credibilite aux yeux du serveur 1, qui pourra ne pas I'exploiter. 

15 Les contraintes precitees se rapportent a la presence ou non d'un 

marquage specifique dans les requetes emises sur le reseau R depuis 
certaines des applications. 

Dans un premier mode de realisation de Tinvention, la couche de 
controle 5 impose aux requetes issues des applications a priori sans confiance 
20 4 d'inclure un marquage associe a cette famille duplications. Une application 
de confiance 3 accede a des fonctionnalites qui lui permettent de contoumer la 
couche de controle 5 et d'emettre des requetes non marquees. En revanche, 
les ressources 6 d'acces au reseau ne mettent pas ces fonctionnalites a 
disposition des applications a priori sans confiance 4. 

25 Dans un exemple illustrant ce premier mode de realisation, le terminal 

2 (par exemple un telephone mobile) dispose d'une machine virtuelle Java, 
pouvant correspondre au module 6 sur la figure. La machine virtuelle permet 
d'executer des applications telechargees ecrites dans le langage de 
programmation Java mis au point par la societe Sun Microsystems, Inc. Toutes 

30 les instructions du langage Java sont executees par la machine virtuelle, qui 
fait appel aux fonctions systeme apres un certain controle. Pour les 




applications Java, on est bien dans un environnement semi-ouvert puisqu'il n'y 
a pas d'appel sans controle aux fonctions systeme. Ce terminal 2 n'est capable 
de telecharger que du code Java, aucun autre type d'application ne pouvant y 
etre installe par I'utilisateur. 

5 L'application a priori sans confiance 4 est alors ecrite en langage Java. 

Dans cet exemple, les protocoles mis en jeu pour les echanges du 
terminal 2 sur le reseau R sont les protocoles HTTP (RFC 1945 ("Request For 
Comments"), publiee en mai 1996 par TIETF ("Internet Engineering Task 
Force")), TCP (RFC 793, IETF, septembre 1981) et IP (RFC 791, IETF, 
10 septembre 1 981 ). 

Le service est heberge par un serveur HTTP 1 qui stocke du contenu 
appartenant a I'utilisateur. II doit s'assurer du fait qu'une requete (demandant 
par exemple I'effacement de tous les fichiers) provient bien de I'utilisateur et 
non d'un programme Java mal intentionne. Ce service est bien entendu 'un 
15 exemple, n'importe quel autre service pouvant etre faire appel a cette 
technique (commerce electronique, publication de documents, messagerie, 
etc.). 

Le marquage peut etre inclus dans le champ d'en-tete "User-Agent" 
des requetes HTTP (cf. section 10.15 de la RFC 1945 precitee). II consiste en 

20 une chaine specifique telle que "Application sans confiance: VM 
Java 1.2" qui indique par sa presence que la requete n'est pas en 
provenance d'une application a priori de confiance. Cette chaine peut etre deja 
presente dans la requete produite par l'application 4, auquel cas la couche de 
controle 5 de la machine virtuelle 6 se contente de verifier sa presence. Sinon, 

25 cette couche 5 Pinsere pour que la requete soit convenablement marquee. 

L'etancheite du marquage applique par la machine virtuelle 6 resulte 
de ce qu'il n'est pas possible a une application a priori sans confiance 4 
d'emettre sur le reseau R des requetes HTTP ne contenant pas cette chaTne 
specifique. En particulier, l'application 4 ne peut pas avoir acces au reseau R 
30 en se branchant sur une couche protocolaire plus basse que HTTP, 
notamment aux sockets TCP. Le marquage est implements directement dans 
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la machine virtuelle 6 dans laquelle I'application a priori sans confiance est 
obligee de s'executer et qu'elle ne peut eviter d'aucune maniere. 

Le serveur 1 peut ainsi trier, parmi les requetes qui lui arrivent, ceiles 
qui proviennent duplications a priori sans confiance 4 et ceiles qui 
5 proviennent duplications de confiance 3 telles qu'un navigateur web. 

II existe des applications qui ne sont de confiance que pour certains 
sites. Par exemple, une applet Java est generalement consideree comme de 
confiance par le site depuis lequel elle a ete telechargee, mais non par d'autres 
sites. Le marquage ne sera done pas toujours n§cessaire dans les requetes 

10 destinees a ce site de telechargement En d f autres termes, la machine virtuelle 
6 peut imposer le marquage aux requetes issues d'une telle applet et emises 
vers un site autre que celui d'ou elle a ete telechargee et laisser Tapplet libre 
d'inclure ou non le marquage dans les requetes qu'elle emet vers son site 
d'origine. Une autre possibility est d'imposer le marquage a toute requete 

15 emise par une telle applet, quelle qu'en soit la destination. 

Une alternative ou un complement au marquage des requetes sans 
confiance peut etre Tinterdiction de certaines de ces requetes. Par exemple, 
pour des applications sans confiance telecharg6es depuis un serveur donne, 
les requetes directes a destination de serveurs differents pourraient etre 
20 interdites. Les requetes a destination du serveur d'origine resteraient possibles, 
avec le marquage. 

Dans une realisation avantageuse, on adjoint obligatoirement au 
marquage une indication de la nature et/ou de Torigine de Implication a priori 
sans confiance 4 dont elle est issue. 

25 Cette application a priori sans confiance 4 peut etre signee. Les 

requetes qui en proviennent serpnt alors marquees avec un en-tete contenant 
au moins Tun des elements suivants, susceptibles de fonder la confiance du 
serveur distant dans cette application: 

• le certificat du signataire de Fapplication, ou un condense de ce certificat; 




• le certificat de la chaTne de certification d'ou le certificat du signataire de 
I'application est issu, ou un condense de ce certificat; 

• une chaTne specialement incluse dans le code de I'application a cet effet; 

• un element variable identifiant I'application de maniere dynamique. 

5 Une telle realisation de Pinvention est notamment applicable dans le 

cas d'une application Java sign6e par un certificat. 

Dans ce cas, la machine virtuelle 6 doit verifier la signature de 
I'application Java avant remission des requetes. En pratique, cette verification 
a lieu avant Pexecution de I'application 4. 

10 Le marquage peut alors consister en Pajout d'une chaTne specifique 

dans I'en-tete HTTP, comme par exemple: "Contenu de confiance - 
Application signee par <C>" ou <C> est la valeur du certificat du 
signataire de I'application, ou un condense de celui-ci. Cet en-tete indique par 
sa presence que la requete est en provenance directe d'un utllisateur, et a ete 

15 creee par un logiciel de provenance connue. 

De cette fagon, si le serveur 1 accorde sa confiance au detenteur des 
clefs privees associees au certificat <c>, le serveur est garanti que Jes 

requetes marquees de cet en-tete specifique correspondent bien £ un accord 
effectif de Tutilisateur. La contrainte de marquage evite que I'application puisse, 
20 aupres du serveur, se reclamer d'un signataire autre que le signataire reel. 

Dans le cas des applet Java telechargees, la machine virtuelle 6 est 
capable ^'identifier Padresse de telechargement de I'application. Elle peut ainsi 
contraindre la requete issue d'une telle applet, a priori sans confiance, d'inclure 
son adresse de telechargement ou des donn§es qui dependent de cette 
25 adresse. 

Dans un autre mode de realisation de I'invention, la syntaxe du 
marquage est inversee: la couche de controle 5 impose aux requetes issues 
des applications a priori sans confiance 4 de ne pas inclure un marquage 
specifique aux applications de confiance 3. 
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Pour se manifester comme etant de confiance pour un serveur 1, une 
application 3 inclut alors le marquage dans la requete qu'elle lui adresse. La 
couche de controle 5 s'assure que ce marquage est absent de chaque requete 
issue d'une application a priori sans confiance 4, le caractere sans confiance 
5 pouvant comme precedemment etre apprecie en fonction du site destinataire 
de la requete. Si le marquage est present dans une requete issue d'une 
application a priori sans confiance 4, la requete n'est pas emise telle quelle: le 
marquage est enleve par la couche de controle 5 et celle-ci peut emettre ou 
non la requete "demarquee" sur le reseau R et prevenir ou non Implication 4. 

io La convention employee pour la syntaxe du marquage doit 

naturellement etre commune au terminal et au serveur, et connue des deux 
avant la transaction. 




REVEWDICATIONS 

1. Procede de communication entre une premiere unite (2) et une 

seconde unite (1) par I'intermediaire d'un reseau de telecommunication (R), 
dans lequel la premiere unite comporte des applications (3,4) appartenant 
5 respectivement a une premiere famille et a une seconde famille presentant a 
priori un degre de conflance plus faibie que la premiere famille, caracterise en 
ce qu'on contraint chaque requete issue d'une application (4) de la seconde 
famille, emise sur le reseau a destination de la seconde unite, a inclure un 
marquage associe a la seconde famille d'applications. 

10 2. Procede seion la revendication 1, dans lequel ledit marquage est 

inclus dans chaque requete emise sur le reseau (R) et issue d'une application 
de la seconde famille (4). 

3. Procede selon la revendication 1 ou 2, dans lequel on contraint le 
marquage, inclus dans une requete emise sur le reseau (R) et issue d'une 

15 application (4) de la seconde famille, a inclure une indication de la nature et/ou 
de Porigine de ladite application de la seconde famille. 

4. Procede selon la revendication 3, dans lequel, ladite application (4) 
de la seconde famille etant signee, on contraint le marquage, inclus dans les 
requetes qui en sont issues, a inclure des donnees relatives a la certification de 

20 la signature. 

5. Procede selon la revendication 3 ou 4, dans lequel, ladite application 
(4) de la seconde famille ayant ete telechargee par I'intermediaire du reseau 
(R) depuis une adresse de telechargement, on contraint le marquage, inclus 
dans les requetes qui en sont issues, a inclure des donnees relatives a 

25 I'adresse de telechargement de I'application. 
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6. Precede de communication entre une premiere unite (2) et une 
seconde unite (1) par I'intermediaire d'un reseau de telecommunication (R), 
dans lequel la premiere unite comporte des applications (3, 4) appartenant 
respectivement a une premiere famille et a une seconde famille presentant a 

5 priori un degre de confiance plus faible que la premiere famille, caracterise en 
ce qu'on contraint chaque requete issue d'une application (4) de la seconde 
famille, emise sur le reseau a destination de la seconde unite, a ne pas inclure 
un marquage associe a la premiere famille, ledit marquage etant inclus dans 
certaines au moins des requetes emises sur le reseau et issues d'applications 

10 (3) de la premiere famille. 

7. Procede selon Tune quelconque des revendications precedentes, 
dans lequel la seconde unite (1 ) examine si le marquage est present dans une 
requete regue sur le reseau (R) depuis la premiere unite (2), pour evaluer un 
degre de confiance a attacher a ladite requete. 

15 8. Procede selon la revendication 7, dans lequel, lorsque le marquage 

est present dans ladite requete, la seconde unite (1) examine en outre des 
donnees incluses dans ce marquage, pour evaluer un degre de confiance a 
attacher a ladite requete. 

9. Procede selon la revendication 8, dans lequel lesdites donnees 
20 examinees par la seconde unite (1) comprennent des donnees relatives a la 

certification d'une signature de I'application dont est issue la requete. 

10. Procede selon la revendication 8, dans lequel lesdites donnees 
examinees par la seconde unite (1 ) comprennent des donnees relatives a une 
adresse de telechargement de I'application dont est issue la requete. 

25 11. Procede selon Tune quelconque des revendications precedentes, 
dans lequel les requetes comprennent des requetes HTTP, et le marquage est 
insere dans les en-tetes des requetes HTTP. 




12. Procede selon Tune quelconque des revendications precedentes, 
dans lequel la contrainte relative au marquage est contr6lee par une couche 
logicielle (5) appartenant a une machine virtuelle (6) dont est pourvue la 
premiere unite (2), les applications (4) de la seconde famille ne pouvant 
acceder au reseau (R) qu'a travers la machine virtuelle et ladite couche 
logicielle. 

13. Procede selon la revendication 12, dans lequel la machine virtuelle 
(6) est une machine virtuelle Java. 

1 4. Terminal de communication (2), comprenant des moyens de mise en 
ceuvre d'un procede selon Tune quelconque des revendications precedentes en 
tant que premiere unite. " ^ 
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